The Recover file is used to support the Save, Save As…, and Revert to Saved menu command, and (more importantly) to protect the existing Collection against change until a save operation is performed. This means that even a power failure does not damage the integrity of a Collection.
In essence, any operation which requires information to be written or rewritten in the Collection file is instead written or rewritten to the Recover file.
For more information about the use of the Recover file, see the Helix Express Reference Manual chapter 10.
The Location of the Recover File
_________________________
Ideally the Recover file should be allocated to the fastest mass storage devices with the largest amount of free space. Unfortunately, the ideal allocation is difficult to achieve.
To begin with, the fastest device may not have much free space on it. To end with, the Macintosh operating system provides almost no information concerning the speed of a device.
We have applied some heuristic methods so as to classify devices by their access path: SCSI, AppleTalk, and Woz. (Woz devices are usually the floppy drive, though there are a few other mass storage devices which attach to this port. By its nature, this port is quite slow, so any device attached to it is naturally quite slow.) AppleTalk devices (usually file server volumes such as AppleShare or TOPS) are also presumed to be slower than SCSI devices, though if the connection is through EtherNet this assumption may not be correct. SCSI devices are usually the fastest around, though the variation in speed among different SCSI devices is quite large.
This heuristic fails when RAM disks are considered. These are very high speed devices, but many implementations make them look like AppleTalk devices. Another area where the heuristic breaks down is with NuBus devices. These may be very fast, but again, their implementation may make them look like either SCSI, AppleTalk, or even Woz devices.
So, we do the best we can. Helix uses its heuristic to implement the following algorithm for choosing a device for the Recover file. It assembles a list of all mounted volumes which meet the following criteria:
• The volume must be online.
• The device must be writable and the volume must be writable (not locked). This
eliminates such things as CD-ROM drives.
For each volume in the list, its free space is determined. The free space is adjusted according to the following rules:
• If the device is not a SCSI device, its free space is set to zero.
• If the volume is the same one upon which the Collection resides, its free space is
reduced by half.
Then the list is sorted and the volume with the most free space is examined. If it has at least 200K free, it is chosen.
If no volume has enough free space, the free space is recomputed, this time allowing AppleTalk devices to retain their actual free space value. Again, the volume with the most free space is examined and if at least 200K is free, it is chosen. If not, Woz devices are added to the mix and Helix tries again.
If no suitable volume can be found, the Collection cannot be opened.
Helix makes a good choice about 99% of the time. However, if you’ve spent $4000 for a 30Meg RAM drive, that remaining 1% will drive you nuts when Helix persists in assigning its Recover file to your 60ms access optical drive.
Controlling the Assignment of the Recover File
_____________________________________
In order to control the placement of the Recover file, Helix Technologies has enhanced the assignment mechanism to allow the user to specify, if desired, where to put the Recover file. This mechanism is currently available in Double Helix 3.5r13 and all versions of Helix Express.
The Helix application contains a resource, type HRFL, ID 0, as do all Collections. This resource is formatted as a string list (resource type STR#), and may contain a list of “places” where the Recover file is preferentially to be placed. A Collection takes on the HRFL settings of the Helix Express application with which it is created. The setting within a collection takes precedence over the setting within the Helix application. If the resource in the Collection is empty, Helix will look at the resource in the Helix application. If the resource in the application is empty, Helix will use the algorithm described above to pick a residence for the Recover file.
If the resource contains one or more properly formatted Macintosh pathnames for a volume where the Recover file should be placed, it is scanned in order, and for each entry, the device specified is interrogated to determine that it meets the minimum requirements for service. That is, it is mounted, online, writable, unlocked, and contains at least 200K of free space. The first specified place that is allowed is used. If none of the entries is usable (e.g., none are mounted), then the algorithm is used. The Recover file will always appear at the root level of the chosen volume (even if you enter a pathname which includes folders).
A ResEdit® template (TMPL) is included in the folder titled "Resources". We have enclosed step-by-step instructions on how to install this ResEdit template, or you can use the ResEdit manual which explains how to install a template. With this template installed, you can use ResEdit to open a Collection file and alter the existing configuration resource (HRFL) to suit your needs.
To insert a slot in the resource, click on 1) ***** (a box will surround the text) and select “Insert New Field(s)” from the Resource menu. A box will appear (as illustrated below) and you can type in a volume name. A properly formatted list has entries of the form:
VolumeName: (the name of the volume followed by a colon (the colon is optional))
As an example, suppose you have a configuration similar to the following. You have a development station which is used to run Helix Express. It has four drives attached to it. They are “SlapShot” which is the system disk and is a 100 Meg volume; “BigGun” which is a 600 Meg optical, “Harvey” which is a 20 Meg RAM disk with battery backup, and “DeadHead” which is another 100 Meg volume. The 30 Meg Collection is on DeadHead. The DeadHead disk moves to the server setup carrying the Collection with it. The server setup has three disks in addition to DeadHead. Its boot drive is called “Millie” and it too has a RAM disk with battery backup, 40 Meg known as “Vanillie”. In addition, there is a optical disk used as a backup device known as “BigHerm”.
At the design station and at the server, the last place you want the recover file to go are the optical disks. But where you really want them to go are the RAM disks. So a good list for the HRFL resource would be: Harvey, Vanillie, SlapShot, Millie, DeadHead.
This covers both machines. Notice that when the Collection is opened at the server station, it will look for Harvey but not find it. So it will go on to Vanillie. Hopefully it will find it, but there is the possibility that Vanillie will break down. You still want the Collection to run, and not off the optical disk either. So the alternate of Millie is there. In either case (server or design station) the backup of DeadHead is present. Of course if the Collection is moved to a whole different environment, the Helix application will fall back on the selection algorithm.
The one pitfall in this set up is the possibility that either someone renames the disks, making the optical “Vanillie”, and the RAM disk “Bernice”. Yes indeed, the recover file will be forced onto the slow optical disk. In fact, merely changing the names of the volumes will foil this scheme.
Finally, be aware that now, due to some internal expansions, the Recover file can become quite large (up to several megabytes) if you do not AutoSave frequently enough.
Helix Technologies makes the information in this document available on an “as is” basis, and is not responsible for its accuracy, use, or future compatibility with either Helix Technologies products or other products such as the operating system.
